In a traditional database system, the transaction management protocols and mechanisms are constrained by the fundamental properties of atomicity, consistency, isolation and durability (ACID). The transaction atomicity, which is the cornerstone of a transaction management system, states that a transaction either runs completely or has no effect on the system at all. The atomicity property indirectly impacts a transaction's ability to view the effects of another transaction while it is executing (visibility) and the database system's ability to recover in case of a failure (recoverability).
In a typical database system, a transaction's ability to view another transaction's uncommitted data is controlled using read locks or multi-version read consistent views of data. Write locks protect a transaction's uncommitted data from being seen and modified by some other transaction. These write locks are held until the end of the transaction and this is required to ensure that the system is recoverable.
A transaction management system with strict ACID properties is effective for conventional database applications involving short execution times (short transactions) and relatively small number of concurrent transactions (operating on the same data). However, it is excessively restrictive for applications that involve reactive, long-lived, and complex transactions.
For example, a complex transaction may involve making the arrangements for a band's world tour. Such arrangements may involve booking many flights, hotels, arranging car rentals, dining, etc. Completing all of the arrangements may take weeks. If the entire “world tour” transaction is modeled using a single database transaction, then certain records may remain locked to other transactions for the entire duration. For example, a record that indicates how many seats are available on a particular flight may remain locked (preventing other passengers from booking seats on the same flight) until the “world tour” transaction either commits or fails.
Keeping records locked for the duration of complex business transactions is impractical and inefficient. However, if a complex business transaction is modeled using several independent database transactions, other problems may occur. For example, assume that a part of a particular business transaction involves increasing the funds in an account. Further assume that the fund increase operation is performed as a distinct database transaction that is allowed to commit before the entire business transaction completes. After the fund increase transaction commits, other transactions are able to see the increased funds in the account. One of those other transactions may be a “withdrawal” transaction that withdraws more funds from the account than existed in the account prior to the funds increase.
If the business transaction that performed the funds increase does not complete successfully, then it will be difficult to undo the changes made by the partially-performed business transaction. In the current example, decreasing the funds of the account to undo the fund increase will leave the account with a negative balance, due to the subsequent withdrawal transaction. To avoid a negative balance, the withdrawal transaction may have to be undone before the fund update transaction is undone. Undoing the withdrawal transaction may necessitate the rollback of one or more additional transactions that relied on the changes made by the withdrawal transaction. Situations like this, where aborting one transaction may necessitate aborting one or more subsequent transactions, are known as “cascading abort” situations.
The Business Transactions Application describes various techniques for freeing up resources before the business transactions that change the resources have successfully completed. According to one embodiment described therein, resources are freed up by committing database transactions that perform portions of operations before the operations themselves have successfully completed. If the operations fail to complete successfully, then “compensation information” is used to remove the effects of the committed changes that were performed as part of the operation. The compensation information indicates the relative effect of the committed changes, so that the relative effect of the changes can be removed without removing the effect of changes made to the resource by subsequent transactions. Because the effect of changes made to the resource by subsequent transactions is not undone, application of the compensation information does not result in a cascading abort situation.
The Business Transactions Application also describes various techniques for allowing database transactions to update values without retaining exclusive locks on those values. Consequently, even before a first transaction that changed a value commits, a second transaction is allowed to change the same value. If the first transaction fails to commit, the effect of changes made by the first transaction are removed by applying compensation information. The application of the compensation information removes only the effects of the changes of the first transaction.
As explained in the Business Transactions Application, a business transaction in the real world is often long lasting, discontinuous, distributed and is able to resume after a system failure. Examples for such business transactions include Travel Reservations, Inventory Management and Provisioning. On the other hand, a database transaction in an RDBMS is typically short lived (to avoid deadlocks and issues with low concurrency), completed within a single thread and is lost in the case of a system failure (assuming the transaction did not commit before the failure). In the absence of a business transaction framework within a database system, business transaction logic is often implemented in the application-tier outside the database system due to this mismatch between a business transaction and a database transaction.
When business transactions are implemented in the application tier, each interaction with an information system (database) is typically modeled using a separate database transaction so that the locks on the modified resources are only held for the duration of the database transaction. Each business transaction has one or more database transactions associated with it. Even though the database transactions are committed, from the business transaction point-of-view, the operations performed on the information systems are considered unconfirmed until the business transaction itself is committed.
Unlike traditional database transactions, which hold the write locks on some modified data until the end of the transaction, a business transaction modeled in the application-tier relinquishes the locks much before the end of the transaction. Hence, concurrent business transactions modify the common data while retaining the effects of other unconfirmed business transactions. To support shared updates to common data (with proper validation) applications often keep track of state information pertaining to each on-going business transaction. When the business transaction is aborted, the same state information is used to generate meaningful compensating operations to undo the effects of a specific transaction while keeping the other transactions intact. The compensation logic is application dependent and is often hand-coded to meet business needs.
The Business Transaction Application describes a framework to manage long-running business transactions in the database. Under this framework, the database server maintains the lifecycle of business transactions and the state pertaining to each business transaction. The framework also supports commonly-used compensation mechanisms as data classification mechanisms—MEASURE and CATEGORY, and the ability to express the compatibility tests for concurrent operations on common data items as declarative operational constraints.
Unfortunately, the pre-built data classification mechanisms (MEASURE and CATEGORY) proposed by the Business Transaction framework may prove too restrictive for a wide range of applications needing custom compensation logic. If applications need compensation logic that does not match the pre-built data classification mechanisms provided by the business transaction framework, applications are forced to revert to using database transactions as surrogates for the business transactions, thus tying up resources for extended durations, as described above. Alternatively, the business transaction logic may still be implemented in the application-tier. Such implementations are often plagued with inefficiencies and/or higher cost of management.
The approaches described in this section are approaches that could be pursued, but not necessarily approaches that have been previously conceived or pursued. Therefore, unless otherwise indicated, it should not be assumed that any of the approaches described in this section qualify as prior art merely by virtue of their inclusion in this section.